撰写敏捷测试象限有了近20年的历史，但还是有很多在做敏捷项目的朋友也没听说过，或者听过但完全不知道是怎么回事。另外，知道敏捷测试象限的业内同仁对它的评价也是褒贬不一。
最近听到几个稍感意外的说法，于是，想跟跟大家一起聊聊这个有名却又颇受争议的敏捷测试象限。
01 敏捷测试象限的演进史
深入了解一件事物，我们有必要了解它的历史演变过程。下文尽量按照时间先后顺序来分享敏捷测试象限几个主流版本的演进，如有不准确的，烦请指出，先行感谢。
1. 原型：敏捷测试矩阵（2003年）
Brian Marick于2003年最早提出“敏捷测试矩阵”的概念，分四个象限，左右分别为支持编程和评价产品，上下分别为面向业务和面向技术。如下图所示：
这是一个专门针对敏捷测试的矩阵，Brian指出左侧的测试主要是为了支持编程所做的准备工作和确保一些问题的澄清，而右侧的测试是关于验证和发现bug相关，左右两侧的“测试”含义不同。
这个矩阵就是我们通常提到的敏捷测试象限的原型。
2. Lisa和Janet的敏捷测试象限第一版（2008年）
Lisa Crispin和Janet Gregory合著的第一本关于敏捷测试的书《Agile Testing: A Practical Guide for Testers and Agile Teams》于2008年12月出版，中文版《敏捷软件测试：测试人员与敏捷团队的实践指南》出版于2010年10月。
基于Brian Marick的“敏捷测试矩阵”，Lisa和Janet在书中正式提出了“敏捷测试象限”，将其中左侧的“支持编程”改成了“支持团队”，将四个象限添加了编号Q1、Q2、Q3、Q4，在每个象限列出了不同的测试类型，还标注了测试是手动还是自动化等内容。如下图所示：
这个敏捷测试象限版本是最为人熟知的版本，是《敏捷软件测试》一书的核心，我们绝大多数人都是从该书中得知敏捷测试象限的。
3. Michael Hüttermann的敏捷测试象限（2011年）
Michael Hüttermann在敏捷测试象限中心增加了“由外而内、无障碍协作”的内容，如下图所示：
其中“由外而内”的思想包括以下几个方面：
- 了解利益相关者和业务上下文
- 更有效地将项目预期与结果对应起来
- 构建更易使用的软件，使系统更易于部署和使用
- 不断加强与利益相关者目标的对齐
而“无障碍协作”主要指的是利用BDD（行为驱动开发）的方式来实现团队无障碍协作。
这部分内容可参考Michael的Agile Record文章查看详情。
4. Elisabeth Hendrickson的敏捷测试象限（2012年）
Elisabeth Hendrickson 2012年在探讨“测试人员思维”时也提出了一版敏捷测试象限，如下图所示：
这个版本跟原来的敏捷测试象限比，除了外观上不同以外，横轴也被修改了，变成了“确认”和“调查”，纵轴则还是“业务”和“技术”两个方向。
- 左上象限代表业务预期，可以是可执行（自动化）规范的形式，也可能由纸质原型或线框表示；
- 右上象限则是有助于调查产品外部质量风险的测试，跟原始象限的探索式测试、场景或易用性测试类似；
- 右下象限突出了系统内部运行的风险。
5. Gojko Adzic的敏捷测试象限（2013年）
Gojko Adzic对Lisa她们提出的敏捷测试象限的有效性提出质疑，尤其是不同意横轴“支持团队”和“评价产品”这两个方向。于是，他提出了自己的敏捷测试象限，左侧为“检查预期输出”，右侧是“分析未定义、未知和意外”，如下图所示：
这里不做过多解读，感兴趣的朋友请移步阅读Gojko的文章《Let's break the Agile Testing Quadrants》。
6. Lisa和Janet的敏捷测试象限第二版（2014年）
Janet Gregory和Lisa Crispin合著的第二本敏捷测试的书《More Agile Testing: Learning Journeys for the Whole Team》于2014年出版，中文版《深入敏捷测试：整个敏捷团队的学习之旅》出版于2017年。书中介绍了新版的敏捷测试象限。
这个版本的敏捷测试象限在原版的基础上进行了修改，但整体的变化不是很大。改动部分主要有：
- 左侧由“支持团队”改成了“指导开发”；
- 去掉了各个象限的测试是自动化、手动还是利用工具的描述
- 对各个象限的测试活动也做了调整。
如下图所示：
在《深入敏捷测试》一书中也有提到前面3、4、5个敏捷测试象限的变种。
7. James Bach和Michael Bolton的敏捷测试象限（2014年）
提出「快速软件测试（RST，Rapid Software Testing）」的James Bach和Michael Bolton对敏捷测试象限有很多的质疑，他们推出了RST的敏捷象限。如下图所示：
这个版本的象限主要是基于RST的理念，从外观上看跟原来的敏捷测试象限很不一样，这里不做详细解读。感兴趣的朋友请自己研究两位作者的PPT去了解。
8. Lisa和Janet的敏捷测试象限第三版（2019年）
2019年，Janet Gregory和Lisa Crispin合著的第三本敏捷测试的书《Agile Testing Condensed》出版，书中再次对敏捷测试象限进行了调整。
为了在DevOps文化领域应用敏捷测试象限，这个版本主要针对DevOps理念对各个象限的测试类型再次进行调整，比如在右上角添加了“生产环境下的测试（Testing in Production）”等。如下图所示：
前面列举的是跟敏捷测试象限相关的多个典型版本，肯定还会有很多其他的版本，这里就不一一调研阐述了。后面主要还是基于Lisa和Janet的敏捷测试象限来探讨。
02 敏捷测试象限的“不足”之处
敏捷测试象限之所以出现这么多个版本，就是因为很多人都认为它是有很多不足之处的，从而搞出自己认为比较完美的测试象限；另一方面，还有些人认为敏捷测试象限没有那么大的价值，不会采用。
我是认可敏捷测试象限的，并不认为真的有什么严重缺陷，也因此我给本节标题的“不足”加上引号。提出负面评价的多数情况是并没有真正理解清楚所致，同时，敏捷测试象限提出者也是持开放态度，可以接受不同的人有不同的想法，模型框架并不是规定非黑即白的东西。
除了前面提到的各位大师的质疑之外，下面我们再来看看身边还有哪些对敏捷测试象限的疑问或误解。
1. Q1-Q4是代表着测试执行的某种顺序吗？感觉不太对啊？
对于这个顺序问题，有很多人对此产生疑问。其实，List他们的书中有明确指出，这四个象限的编号跟测试执行顺序没有任何关系，完全是为了描述的方便。比如，Q1就是指面向技术的支持团队的测试，用Q1来描述比那一长串文字要简单很多。
有意思的是，第三版象限中去掉了Q1-Q4的标识，其实我觉得继续保留挺好的。
2. 四个象限指出是自动化还是手动是有问题的
这里基于当时敏捷测试象限里列出的测试类型，在当时的环境下我们可以认为是问题不大的，只不过随着科技的发展，对不同测试的执行发生了变化，几年后的确稍显过时。因此，我在给人讲这个象限的时候会说是需要自动化还是手动执行，不是死的规定，需要根据情况来看。
同样，第二版敏捷测试象限中也去掉了这部分内容。保持开放，接受反馈，持续演进，这是很赞的。
3. 象限里提到的测试有些根本不适用，没有参考价值
这一观点的误区在于认为四象限列了什么类型的测试就有什么，没列的没有，列了的都有，不存在按需增减这种事情。
敏捷测试象限的三个版本对于提到的测试类型都有所不同，都是基于当时环境下列举的相对完整的集合，肯定不会适用于所有的团队，要真正使用需要做定制化裁剪或调整。现实世界太复杂了，不仅敏捷测试象限如此，任何模型、框架都应该是如此，不可能是放之四海而皆准的。
4. 象限是不完整的，需要添加一些测试类型，或者需要调整一些测试所处象限
Lisa对此也有说明，原文链接在这里《Using the Agile Testing Quadrants》：
“The quadrants are merely a taxonomy to help teams plan their testing and make sure they have all the resources they need to accomplish it. There are no hard and fast rules about what goes in what quadrant. Think through them as you do your release, theme, and iteration planning, so your whole team starts out by thinking about testing first.（象限只是一种分类方法，用于帮助团队计划测试，并确保获得完成测试所需的所有资源。关于测试活动进入哪个象限，没有硬性规定。需要在做发布和迭代计划时仔细考虑，以便整个团队对测试引起重视。）”
当我们提到要持续性能测试的时候，在左侧支持团队的测试里可能就要开始考虑性能测试了；同样，安全测试也不仅是用工具来扫描的面向技术的测试，我们需要考虑的更多的是跟业务相关的安全问题，我之前在“一页纸测试策略”里提到的蓝鲸项目，就是把业务方向的安全测试放在右上角的Q3里面。
并没有任何地方指出敏捷测试象限列举的测试类型是完备的，它给出的只是个参考。正因为这个原因，才会有三版不同的敏捷测试象限，那是与时俱进不断完善的结果。
5. 我不会推荐敏捷测试象限，那就像是一个字典，没什么大用
这个观点理解软件开发这个复杂环境下不能通过查字典的方式来确定需要采用的测试，为啥就不能正确理解敏捷测试象限的真正价值呢？
前面已经解释过了象限里的测试类型不是死的，不是完备的，不是硬性规定，因此也就不是字典。
6. 敏捷测试象限是乙方视角，其中有些测试是要自证质量才会引入的实践
“四象限是乙方视角，那些UAT啊还有服务团队相关的一些测试，是因为存在甲乙方的关系，我要自证我的质量，才会引入的实践……”
说实话，听到这个观点我挺意外的。这里存在两个方面的误解：
- 对某些测试类型的误解
- 对象限的误解
6.1 对某些测试类型的误解
认为某些测试类型的命名是乙方视角，那是对测试类型的误解，也是没理解相关测试的真正价值，有必要说明一下。以UAT为例，先看看维基百科对UAT的定义：
我的理解跟维基百科定义是类似的：用户验收测试主要是以用户的角度验收所开发的系统是否能够满足用户需求，这个测试不一定是很严肃的一个测试环节，根据不同团队以及产品的具体情况，会有不同；而且名称可以不叫UAT，但是事情的目的一样，比如beta测试，也是验证用户的使用接受情况。
另外，这不存在甲方乙方视角问题，不管是甲方做还是乙方做，软件开发团队和用户（或业务方）基本都不会是一个团队，就算业技融合很好、且很难触及真实用户的团队，团队里边角色（帽子）还是会有不同，还是会需要那个所谓的SME（相对更精通业务领域的人）来从用户视角进行验收的，可能是PO、也可能是测试人员，或团队其他角色。
当我们理解这个测试实践背后的真正价值，认为这个事情是需要做的，就不会产生这样的误解了。
6.2 对象限的误解
另一个方面的误解跟前面的3、4、5的观点有些类似，同样也认为象限里列举的测试类型就是固定不变的，前面已经解释过，这是没有理解象限的真正含义。
如果正确理解四象限的意义，也就不会有甲方或乙方视角问题了，事情很简单，如果觉得这些名称属于乙方视角，可以根据自己的语境来定义自己认为适合的测试就好了。
03 敏捷测试象限的正确使用方式
了解了敏捷测试象限各个不同的版本的演进过程，下面来总结一下它的正确使用方式：
1. 敏捷测试象限不是规则，而是测试策略制定的指南
象限提供四个不同的思考维度，给团队制定测试策略提供参考分类方法，这是象限的伟大之处，是核心所在。它能够帮助团队在制定策略的时候全面思考，从而制定出合适的策略。
推荐的使用方式是在制定测试策略的时候，让团队讨论可能需要的所有类型的测试活动，做到尽量的全面。通常可以在大白纸上画出空的象限图，团队一起头脑风暴，使用便签在各象限贴上相应的活动，如果发现某个测试活动的位置不对，方便随时移动。
2. 敏捷测试象限不是银弹，不能生搬硬套
就像测试金字塔不是银弹一样，敏捷测试象限也不是银弹，不能直接套用三个象限版本中的任何一个，也不能直接套用别的团队的象限。前面提到过象限的测试类型不是全集，也不能当做字典来查询。
正确的使用方式是参考象限模型的分类法，需要根据自己项目团队的情况进行定制化，构建自己团队适配的象限。并且，定制化的象限图也不是一成不变的，而是需要根据不同时期团队的不同特点进行调整优化，持续演进。
另外，注意更新工具箱。虽然前两版在象限划分思路上没有什么问题，但最好参考第三版，毕竟它是比较新的。
3. 敏捷测试象限不仅适用于敏捷开发模式
虽然叫做“敏捷”测试象限，也是源于敏捷开发模式下对各种测试类型的思考，但其实不限于敏捷，对瀑布等其他开发模式同样适用。
象限的精华是几个象限维度的划分，是指引策略的方向，不管什么开发模式，从这几个维度来思考都是没有问题的，只是不同维度下具体的测试类型可能会稍有差异，根据团队实际情况考虑就行。
4. 敏捷测试象限还可作为技能集参考
有人将敏捷测试象限用作新人技能集的评估参考，这是很有意思的事情。其实，我们制定策略考虑到的不同测试活动，就需要有相应的技能去实施，所以这么用也是完全没问题的。同样，除了评估新人，也可以当成能力模型，帮助指导团队人员的能力建设。
04 写在最后
任何框架、模型、工具都不是用来生搬硬套的，需要了解背后真正的逻辑，理解其真正的价值所在。
敏捷测试象限的真正价值是四个象限的思考维度，不要过多关注每个象限里到底有哪些测试活动。记住这一点至关重要！
05 推荐阅读
下面文章有关于敏捷测试象限的更多详情，推荐阅读：